Current software anti-reverse engineering techniques are often only marginally effective. Code obfuscation can only slow down the process of static analysis because the logic is still basically the same and exposed. Anti-debug and anti-disassembly techniques can only trick current versions of debuggers and disassemblers and can be disabled manually if attackers spot the tricking instructions. Code encryption must at some point leave the decrypted code in memory for execution, not to mention that the key used for decryption must be embedded somewhere in the program which can be revealed. Some protection schemes use many layers of protection but eventually have to leave the outermost layer unprotected and therefore attackers can cascade attacks from there.
Every lock on earth relies on the complexity of the key. But if the key is embedded inside the lock, its complexity becomes trivial. This is the common fundamental weakness of the techniques mentioned above, for they all can be put in one category: security through obscurity. That is, the key to unlock the protection mechanism is still embedded inside the software program and in theory can never escape complete logic analysis. Therefore, no matter how complicated the programmer writes the code, the complexity of the key only scales linearly with that of the whole protection scheme. With a combination of debugging and tracing tools, attackers can quickly analyze and find out the logic of the key in linear time.
This challenge does not exist in cryptography where the key is not present at all in the encrypted file and the searchable key space expands exponentially with the complexity of the protection mechanism. Unfortunately, cryptography cannot be applied directly for code protection since the processor only accepts assembly language which is publicly known and not encrypted. Thus, the key must be included for decryption should the code be encrypted.
While systems and methods are described herein by way of example and embodiments, those skilled in the art recognize that systems and methods for anti-reverse engineering for software are not limited to the embodiments or drawings described. It should be understood that the drawings and description are not intended to be limited to the particular form disclosed. Rather, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the disclosed embodiments. Any headings used herein are for organizational purposes only and are not meant to limit the scope of the description or the claims. As used herein, the word “may” is used in a permissive sense (i.e., meaning having the potential to) rather than the mandatory sense (i.e., meaning must). Similarly, the words “include”, “including”, and “includes” mean including, but not limited to.